Currently, RAID systems are the principle storage architecture for large networked computer storage systems. RAID architecture was first documented in 1987 when Patterson, Gibson and Katz published a paper entitled, “A Case for Redundant Arrays of Inexpensive Disks (RAID)” (University of California, Berkeley). Fundamentally, RAID architecture combines multiple small, inexpensive disk drives into an array of disk drives that yields performance exceeding that of a Single Large Expensive Drive (SLED). Additionally, this array of drives appears to the computer as a single logical storage unit (LSU) or drive. Five types of array architectures, designated as RAID-1 through RAID-5, were defined by the Berkeley paper, each providing disk fault-tolerance and each offering different trade-offs in features and performance. In addition to these five redundant array architectures, a non-redundant array of disk drives is referred to as a RAID-0 array. RAID controllers provide data integrity through redundant data mechanisms, high speed through streamlined algorithms, and accessibility to the data for users and administrators.
File systems within RAID networks maintain an abstracted view of the files and directory structure within mass-storage to a user, such that information can be effectively managed by the application without user knowledge of the physical memory locations of the files. File systems allow users to create files and directories, as well as delete, open, close, read, write and/or extend the files in memory. File systems also maintain security over the files that they maintain and, in most cases, manage control lists for a file. Volume management was developed in the late 1980s to enable the creation and management of file systems larger than a single disk, typically via striping. Striping is a method of concatenating multiple drives into one logical storage unit. Striping involves partitioning each drive's storage space into stripes, which may be as small as one sector (512 bytes) or as large as several megabytes. These stripes are then interleaved so that the combined space is composed alternately of stripes from each drive. In effect, the storage space of the drives is shuffled like a deck of cards. The type of application environment, I/O or data intensive, determines whether large or small stripes should be used. The choice of stripe size is application dependant and affects the real-time performance of data acquisition and storage in mass storage networks. In data intensive environments and single-user systems which access large records, small stripes (typically one 512-byte sector in length) can be used so that each record will span across all the drives in the array, each drive storing part of the data from the record. This causes long record accesses to be performed faster, because the data transfer occurs in parallel on multiple drives. Applications, such as on-demand video/audio, medical imaging, and data acquisition, which utilize long record accesses, will achieve optimum performance with small stripe arrays.
Striping requires interaction between the volume manager and a disk management system that configures and allocates space within a RAID memory unit. There are numerous methods of file system configuration and allocation. “Metadata” is data that describes data, and in this application, it is configuration and allocation information that describes the position and attributes of user data on the memory unit. Typically, an operating system stores metadata in a fixed location on the memory device that records stripe and configuration information for a given file. A volume is a logical unit of data storage that may correspond to a physical memory device, such as a disk drive, or that may include fractional or multiple memory devices. When a volume is brought online upon power-up, for example, the information needed for the volume to be available to a host is read from an area of memory on the volume designated as the configuration space. The configuration data includes, for example, volume size and file attributes, such as read/write, or read only. As a result, when the volume returns online, it will be configured as it was prior to the power cycle, and its data will be made available to the user. Currently, however, the number, type, and location of configuration data is vendor specific; its functionality is limited and is rigidly fixed for the life of the disk. In practice, however, there are a number of instances in which it would be desirable to have configuration data flexibly altered. For example, configuration data may be optimized for a given storage application. Unique configurations to accommodate different applications are known as “personalities.” As changes to a memory unit application occur, changes to configuration personality data is also likely to occur. In current technology, any changes to the configuration data require costly maintenance; specifically, the disk needs to be re-formatted prior to any changes being made to the configuration data. These limitations to the configuration data are problematic for the providers of RAID network services because of the dynamic nature of RAID networks. What is needed is a flexible means of updating the configuration for a disk drive in RAID network, such that the metadata is not restricted to exact format or location in memory. Further, what is needed is a way of providing RAID network configuration data, beyond what is currently available, so that the RAID network can be optimized for special applications.
An example of an invention for a method of disk configuration for a RAID network is U.S. Pat. No. 6,138,126, entitled, “Method for Allocating Files in a File System Integrated with a RAID Disk Sub-System.” The '126 patent describes a method for integrating a file system with a RAID array that exports precise information about the arrangement of data blocks in the RAID subsystem. The file system examines this information and uses it to optimize the location of blocks as they are written to the RAID system. Thus, the system uses explicit knowledge of the underlying RAID disk layout to schedule disk allocation. The method uses separate current-write location (CWL) pointers for each disk in the disk array. The pointers simply advance through the disks as writes occur. The algorithm used has two primary goals. The first goal is to keep the CWL pointers as close together as possible and thereby improve RAID efficiency by writing to multiple blocks in the stripe simultaneously. The second goal is to allocate adjacent blocks in a file on the same disk and thereby improve read back performance.
While the '126 patent provides an efficient means of disk configuration for a RAID system, the invention does not provide a flexible means of providing configuration metadata in a RAID system in a way in which the metadata is not restricted to exact format or location in memory. As a result, the '126 patent does not ensure that the RAID file configuration is independent of the memory devices used to implement the network.
Configuration metadata stored on storage devices often needs to be updated because of configuration changes or enhancements. Currently, the process of updating configuration metadata can create situations in which the larger size of a new format of configuration metadata may overwrite other metadata, forcing the other metadata to be moved to new locations. This requires that both configuration metadata layouts are tracked to ensure that corruption does not occur. It also requires that newer versions of firmware have awareness of all older metadata formats so that devices with an older metadata format scheme can be handled properly by newer firmware. What is needed is a way to simplify the storage and retrieval of storage device metadata.
It is therefore an object of the invention to provide a way to simplify the storage and retrieval of storage device metadata. More specifically, it is an object of the invention to provide a flexible means of configuring a disk drive in RAID network, such that the metadata is not restricted to exact size, format or location on a storage device.
It is yet another object of the invention to provide a flexible means of updating the configuration for a disk drive in RAID networks, such that the metadata is not restricted to exact format or location in memory. Furthermore, it is yet another object of the invention to provide RAID network configuration data, beyond what is currently available, so that the RAID network can be optimized for special applications.